Evaluating connectivity on data-communication networks

ABSTRACT

For the benefit of a reference ISP having a number of users, connectivity evaluations on a data communication network are performed relative to one or more ISPs of interest. Upon selecting a plurality of autonomous systems capable of forming a traffic source and/or destination for the users of the reference provider, tables of the BGP type are provided containing information on the paths available on the network for routing the traffic with regard to the above-mentioned autonomous systems. From these tables the paths of BGP type are extracted for the respective provider or providers of interest, searching for the paths that contain the respective AS number for the provider and/or providers of interest. For each autonomous system the oriented subpaths are extracted between each said autonomous system and the provider or providers of interest, identifying for each subpath the respective number of hops.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is the US national phase of PCT applicationPCT/EP2003/009692, filed 1 Sep. 2003, published 11 Mar. 2004 as WO2004/021650, and claiming the priority of Italian patent applicationTO2002A000762 itself filed 2 Sep. 2002, whose entire disclosures areherewith incorporated by reference.

FIELD OF THE INVENTION

The present invention concerns the techniques for performingconnectivity evaluations on data-communication networks, such as theinternet.

The solution according to the invention has been developed takingparticular care of the problem of performing connectivity evaluationswhich may be used for instance for establishing peering relationshipswith specific internet service providers (ISP). For evaluating theopportunity of establishing co-operation relationships with a givenprovider it is important to make use of technical tools capable ofsupplying, for a given provider or Candidate ISP, an objectiveindication of the connectivity of the candidate itself, meant as thecapability of the provider of meeting specific needs concerning thecontents available and the procedure by which the information contentsare made reachable over the network.

BACKGROUND ART

The routing over different domains on the Internet is performed throughthe protocol known as Border Gateway Protocol (BGP). For a generaldiscussion of the characteristics and modes of use of the BGP protocolreference may be made to the document “A Border Gateway Protocol 4(BGP-4)” by Y. Rekhter and T. Li, RFC 1771, T. J. Watson ResearchCenter, Cisco, March 1995.

The BGP protocol allows each autonomous system (AS) to adopt its ownpolicy in selecting the paths and propagating the reachabilityinformation on the other network users. These routing policies mayhowever be dependent upon contractual commercial agreements amongdifferent administrative domains. For instance, an autonomous system ASmay choose the policy of not providing transit services among itsproviders.

An evaluation of a provider connectivity, solely referred to the“technical” capability of a provider of transmitting information overthe network, may be obtained by making resort to various solutions,commonly known in the present is art. However, such a solution is notcapable of characterizing in a complete and fully correct way thefeatures of a network such as the Internet.

Solutions have already been worked out which allow it in some way toinfer the existence of specific customer/provider relationships on thenetwork.

A solution of this kind is described for instance in the document “Oninferring autonomous system relationships in the Internet” by Lixin Gao,GLOBECOM 2000-IEEE Global Telecommunications Conference, no. 1, November2000, pages 387-396.

The solutions according to the present art considered above have in anycase the drawback of providing in the whole a partial overview of theconnectivity characteristics of the network, in particular concerningthe overwhelming weight given to the physical transport characteristicsof the network itself.

OBJECT OF THE INVENTION

The present invention has the purpose of providing a enhanced solutionso as to overcome the limits involved in the solutions according to theknown technique, described before.

SUMMARY OF THE INVENTION

According to the present invention this aim is attained by virtue of amethod having the characteristics specifically recalled in the claimsappended hereto.

The invention also concerns the corresponding system and informationtechnology product, which can be directly loaded in the internal memoryof a digital computing unit and includes portions of a software code,capable of performing the procedure according to the invention when theproduct is run on a computer.

BRIEF DESCRIPTION OF DRAWINGS

The invention will now be described by way of a non-limiting example,with reference to the attached drawings, wherein:

FIG. 1 depicts in general terms the context of possible application ofthe invention,

FIG. 2 is a functional block diagram illustrating the generalarchitecture of a system according to the invention;

FIG. 3 is a flow chart illustrating the mode of operation of a systemaccording to the invention, and

FIGS. 4 and 5 show two sorted lists of connectivity values, which can begenerated according to the invention.

BEST MODE FOR CARRYING OUT THE INVENTION

In the diagram of FIG. 1, there is denoted by 10 a first provider (ISP)which is identified in the sequel as a “reference” provider or ISP. Tothe reference provider are connected a set of respective users, denotedby C. Such users are interested in reaching or in being reached by a setof Autonomous Systems, ASs, belonging to the Internet and denoted astarget ASs. To allow the traffic from and towards the AS systems of thegroup T, which may act as a traffic source and/or as a trafficdestination for the users C, the ISP 10 cooperates with a set ofadditional ISPs, collectively denoted by 12, with which a so calledpeer-to-peer relationship has been established.

The system herein described is designed to perform connectivityestimates to evaluate the opportunity of establishing peeringrelationships with one or more providers, collectively indicated by 14,and generally defined as ISP “candidates.” Each Candidate ISP istherefore at least potentially designed to add to the ISP 12 or toreplace one of them.

Usually, due to the general complexity of the Internet, the target ASsof the group T are not directly reachable through the providers 12 or14. The traffic is then routed through further additional providers,denoted collectively by 16, which however do not take up any specificrelevance within this description.

The system according to the invention makes resort to the databasesessentially formed by the so called BGP tables and/or by similar tables,generically denoted by BGP1, . . . , BGPm, in FIG. 2. These tables maybe supplied by appropriate public route servers, be derived fromsubjects toward which the connectivity evaluation must be mainlyperformed (i.e. the candidate ISPs 14) in other terms they may be stillderived from the ISP suppliers 12.

It is therefore evident to the those skilled in the art that thesolution according to the invention can be applied by using either thestrictly defined BGP tables or by tables structurally similar orfunctionally equivalent to the BGP tables under question: for thisreason in the claims which follow, reference will be generally made totables of a “BGP type,” in order to include within the invention alsosuch similar or equivalent tables, the same considerations beingapplicable also to the extraction function of the BGP paths, which areto be dealt in the sequel.

The BGP tables essentially form a database wherein three parts may bedistinguished (at logical level):

a first part, currently called Adj-RIBs-In, contains informationcollected from the incoming updating messages; the content of this partare the routing paths available as input for the decision process of theBGP procedure;

a second part, called Loc-RIB, contains the local routing information,that has been selected by applying the local policies to the routingdata contained in the database part called Ad-RIBs-In; and

a third part, called Adj-RIBs-Out, where the information is stored inview of the advertisement function to the subjects considered as“peers,” with which the communication is performed through the BGPprotocol.

The routing information which is stored in such a data-base is organizedin a set of information elements, as listed below, namely:

IP destination network, and

the string (called AS-path) describing the autonomous systems to betraversed in order to reach such an IP destination network.

This information is designed to be conveyed into the update messagessent toward the outside in the advertisement function directed to thesubjects characterized as “peers.”

Within the context herein considered, “peer” means in general anotherautonomous subject (AS) acting on the Internet and with which there is aco-operation relationship aimed at the traffic exchange and performedthrough the interconnection of at least two routers, one for each ISP,and the configuration of BGP peering sessions.

The system S described herein is designed to work on traffic datacollected in a known way, acting for instance through passive probes,e.g. by means of the software product known under the trade name ofCisco IOS NetFlow™, made available by Cisco Systems Inc. (U.S.A.). Theproduct makes it possible, through its different applications, tocollect various data concerning the operation of a data-communicationnetwork such as the Internet, allowing for instance a detection of thetraffic flows and an aggregation of the information being collected onthe basis of various classification criteria: it is thereby possible tocompute the traffic volumes directed to or coming from a particulardestination/source.

The use of this product and in particular of the “NetFlow Switching”function working on the network nodes is usually the most economicalsolution, although it may be necessary to double-check that the on-boardrouters of the reference ISP 10 of FIG. 1 are capable of accepting theuse of additional resources, required for collecting and exporting thetraffic data.

Both the BGP tables and any traffic data collected are preferablypre-processed (for instance acting in a known way through so calledauxiliary scripts) so that for instance the BGP tables have beencleaned-up of the comments, and the files relating to the traffic dataare made available in order to be processed for further aggregations, asa function for instance of the autonomous system (AS) acting as a sourceor as a destination.

In FIG. 2, the blocks CL1, . . . , CLm stand for corresponding cleanupfunctions (removal of comments, etc. designed to work on the tablesBGP1, . . . , BGPm, while the references BGP1′, . . . , BGPm′ representthe tables BGP resulting from the cleanup performed by functions CL1, .. . , C1 m. After the cleanup, the BGP tables may be seen as merginginto a corresponding list denoted by L1.

The reference TD instead indicates in general the traffic data collectedthrough a function collectively denoted by CF (it may be for instancethe NetFlow™ function, already mentioned before), while SM indicates apre-processing function, the purpose of which is to allow additionalprocessing on traffic data.

The SM function can be a simple program, written for instance in VisualC++6.0, in the form of a console application capable of aggregating thefiles relating the traffic data, by aggregating them for instance bysource or by destination ASs.

The application of the SN function leads back to the formation of twotraffic data files FI and DI, which refer to the forward traffic and thebackward traffic, respectively. The meaning of such terms will be betterunderstood in the sequel. Files FI and DI may be considered as forming atraffic data list, denoted by L2.

The lists L1 and L2 are typically configured as files and are in turncapable of merging into a configuration file FC wherein the namescorresponding to the lists or tables L1 and L2 are written in the FCfile in the appropriate lines, specifying the data path so as to preventits execution from overlapping with the previous ones.

The ASB reference indicates a file corresponding to the list of the ISPsof interest, i.e. of the subjects for which a connectivity evaluation isrequested. This term applies primarily to the ISPs whose connectivitycharacteristics are to is be estimated, so as to evaluate-on the basisof objective data, supplied by a technical instrument, such as thesystem according to the invention-the opportunity ofestablishing/confirming/modifying peering relationships.

The solution according to the invention is suitable for application inat least two essential contexts, namely:

the evaluation of the opportunity of establishing peering relationshipswith one or more candidate ISPs candidates 14 and/or confirming therelationships with one or more ISP suppliers 12, with the possibility ofdefining a priority/suitability classification in in order to establishthe relationships: it is therefore an application, which in its finalresults is configured as an off-line and non-real time application; and

the possibility, having identified a set of “peers” and defined therelationships with them, of executing interventions for re-balancinginformation flows, aimed at an efficient use of the peering links and atan optimized transmission of the traffic for the users; in such a casethe technique according to the invention may be obviously used on-line.

The re-balancing interventions which have just been mentioned, areusually performed at time instants rather distant from one another,being foreseen for instance the execution of connectivity evaluations atinterval of different hours from one another.

The solution according to the invention is suitable for both theexecution at a first order or level, in which each ISP listed in the ASBfile is evaluated by itself, and for the performance, at a second level,of aimed execution of an evolving kind. In the latter case, all the ISPsof interest recorded on the ASB file are in general considered, causing,as a function of the script executed at the first step, the execution oftwo further scripts.

The first of them creates a file of the ISP combinations with thespecified sub-sequence, whilst the latter computes the connectivity ofthe different tuples of ISPs.

The results of the re-processing operations previously described arecollected in corresponding files FIX, BIX, FIY and BIY, which containthe connectivity evaluations, forward FIX and backward BIX, for theX-the ISP taken into account toward/from each of the subjects, i.e.content suppliers (ASs), toward which and from which non-zero trafficvolumes have been recorded. In each file there is a line for each pairconsidered-ISP/target-AS containing the AS identifiers of the X-the ISPunder question and of the target AS, and the connectivity valueestimated by the methods described in the sequel. FIY and BIY are thecorresponding files relating to the Y-the ISP of the plurality (ASB).

These files are shown because they may be used as criteria for thedistribution of the traffic in the second application identified above.

The reference CE denotes in FIG. 2 the set of information (formingactually the output data of the system according to the invention),containing the evaluations of total connectivity for each tuple ofcandidate ISPs.

As will be better seen in the sequel, such data may concern for example:

the algebraic sum, for each autonomous system AS acting as a target, ofthe connectivity of each of the IPSs included in the tuple beingconsidered from/toward the same target AS; or

the application of a criterion such as the assignment, as connectivityof the entire tuple toward/from a given target AS, of the max.connectivity toward/from the same target of each of the ISPs forming thetuple, or

a cut-off function with appropriate contained modifications to the codeof the script.

The cut-off function acts in such a way that, if the algebraic sum ofthe connectivity values of each of the ISPs forming the tupletoward/from a given target AS, divided by the traffic volume toward/fromthe same target AS exceeds a given value, the connectivity value of thetuple is set equal to such a threshold, multiplied by the traffic valuetoward/from the target AS. The determination of applicable thresholdvalues may result from appropriate executions of the method itself.

Leaving apart the general flow of information collection and processingrepresented in FIG. 2, it must be noted that the individual functionsand operations represented by each of the blocks which appear there areperformed according to known criteria as such, thus making a furtherdescription in this context unnecessary.

With regard to the pre-processing of data traffic TD by the SM function,it is possible to aggregate the data for a given period, for instancethree days, by first creating the aggregates of each day, and thenmaking a further execution that processes the aggregated data of eachday.

All the above must be carried out taking also into account the fact thatin case of interfaces toward the so called BIG Internet (i.e. theinterfaces toward the present ISP suppliers, denoted by 12, i.e. towardthe outside), the systems of interest are the ASs of origin, whilst incase of interfaces toward the inside (i.e. toward the C users of thereference ISP 10) the systems of interest are the ASs destinations ofthe traffic.

This is due to the fact that a collection tool, such as the NetFlow™function represented by the block CF, in its most spread version atpresent, only classifies the traffic received at the interfaces.

In the case of use of NetFlow for collecting the traffic simultaneously,two or more different threads can be used in parallel, each of themcharacterized by adequate filters such as to identify on each borderrouter in the one case the interfaces toward the BIG Internet (externalinterfaces) and in the other the interfaces toward the inside. As amatter of fact it is preferred that the statistics of the trafficreceived are sorted according to the traffic direction (from theInternet, toward the Internet) already at the level of the basiccollection through Netflow Collector (since the adopted aggregation doesnot show disaggregated data for each interface).

Furthermore, the border routers of the reference ISP 10 must bepreferably so configured as to effect, for each IP flow, the associationwith the AS systems of origin and destination, and not with those seenas “peer-as” (i.e. those immediately preceding and immediately followingin the information transmission chain).

Obviously, it also possible to envisage an option whereby the routerassociates to the flow the number of the AS system from which thepackets arrive as origin and the number of the AS system to which thetraffic is delivered as destination.

Instead, as to the functions CL1, . . . , CLm that carry out theclean-up of the BGP tables, it is preferred that the same tableseliminate all the initial and final comments and any other commentspresent between the valid lines so as to also recover valid lines,broken on two or more lines, i.e. not correctly terminated. The relatingoperation must be effected for each of the tables to be processed.

In this regard it must be noted that not all the public router serverssupply a file already ready in a compressed format. To download the BGPtable of a router server (subject to authorization of its managing part)an appropriate script, of a known type, is usually required, which byconnecting via telnet to the router server makes it possible to requestthe table by block of n lines so as not to overload the CPU of therouter server, thus avoiding, through an appropriate control characterfor every n lines, possible time out problems during the telnet sessionwith the same router server, due to the transfer time of the table.

The ratio between the number of BGP paths and the number of the IPnetworks provides an estimation of the plurality of available sources.The downloading of the complete tables requires however a high-levelscript, capable of interacting in place of the human operator with theroute-server, since the tables under question may consist of somemillions of lines.

Preferably, in order to ease up the use of the system according to theinvention, auxiliary scripts are foreseen for the preparation of the BGPtables, displaying their begin or final part, since these files areextremely large.

As has already been mentioned here several times, the system accordingto the invention is suitable for evaluating the connectivity for thebenefit of a reference ISP with regard to one or more ISPs, such as forinstance the candidate ISPs 14, in order to establish possibleconnectivity agreements. The system according to the invention hereinillustrated makes it possible for this purpose to take account of theactual traffic present at the reference ISP 10, so that the startingpoint is therefore formed by a collection of traffic statistics effectedon the network of such a reference ISP, at least at the internal andexternal interfaces of the border routers of the same client. Thesolution described here allows it to set-up a sorted list of ISPs ofmost convenient use for transmitting traffic toward the target ASs inthe Internet and for receiving traffic from the same, such an evaluationduly taking into account the actually experienced traffic.

Passing now to the flow chart of FIG. 3, we will see that the reference100 indicates a standard start step after which, at a step denoted as awhole by 102, the system S carries out the extraction of the informationcontained in the BGP tables denoted by the references BGP1′ to BGPm′.

The execution of such step involves the reading of correspondingconfiguration files and a list of ISPs of interest (see step 102, FIG.3).

Such a list, stored on ASB, may include both candidate ISPs 14, andpossibly ISPs that are already included within the ISP suppliers 12.

Therefore the reading is effected of number of ISPs to be considered,and of coefficients of the weight functions to be subsequently used, andadditionally the definition is made of the number or tuple of thepeering relationships the reference ISP 10 wishes to establish.

It is also necessary to carry out the reading of the traffic filescollected thanks to the CF function. Such files are read starting froman aggregation by autonomous system AS and with the subsequentprocessing SM that aggregates them according to source AS or todestination AS, and carrying then out the loading in associative arrays,represented by DI and FI in FIG. 2, using as a key the AS number and asa value the number of the traffic bytes.

It will be appreciated that such a formalism, which is also used in thesequel of the present description, makes reference to the possibleadoption, for implementing this invention, of the programming languagecalled PERL. This choice, though being preferred at present, isobviously neither mandatory nor binding for the implementation of theinvention.

The next step is then the computation of the combinations of tuples andthe writing of a corresponding file. To this end, the starting point isthe list of the AS numbers contained in ASB and among them a first setor group of ISPs of interest is then considered.

On this ISP group of interest all possible tuples are computed, and thena combination per line is written in the resulting file.

At a subsequent step, globally indicated by 104, the actual extractionis carried out of the information from the BGP tables as well as theextraction of the BGP paths concerning the ISPs of interest.

To perform the first function, on each table cleaned-up of the comments,a search is made of lines capable of satisfying specifiedcharacteristics described by predefined patterns, for instance thepresence of a sequence of characters of IP address type, in the A. B. C.D. form (where A, B, C, and D are decimal digits) at the beginning ofthe line after three characters. From each line satisfying the requiredcharacteristic the AS path is extracted (see step 104, FIG. 3) and thenset in a line of the output file. The path is preferably identifiedstarting from the bottom of the line by the character terminating the ASpath (“i,” “e” or “?”) up to the first zero.

The preferred procedure envisages the reading of a line at a time andeach line being read, is subdivided into strings, using as separationcharacters such as “space” and “tab.” The extracted path is written in aline of a temporary file. Such a file is then opened and for each ISP ofinterest the paths are searched containing the AS number of the ISPunder question.

At this point, the AS path is subdivided into two parts. The first part,from the ISP to the last element of the AS sequence (ASM), convergesinto the forward or upstream file, denoted in the sequel by FPX; thesecond part, from the first element of the AS sequence (AS1) to ISP,converges into the backward or downstream file, denoted by DPX. Thus,there is a pair of files FPX and DPX for each ISP of interest.

By “forward” we obviously mean the information relating to the way therest of the Internet is reached, from a given ISP, whereas by “backward”we indicate all information arriving at a given ISP from the Internet.

The FPX and DPX files are therefore submitted to a compacting operationby using associative arrays that have as a key the AS path for avoidingrepetitions of the same. This is done for the reason that each sequenceappears only once and at the end the associative arrays are writtenagain in the files by only writing the keys.

At the subsequent steps indicated here on one side by 106,108, 110 and112 and on the other by 114,116 and 118, the computation is performed ofthe connectivity with traffic weights defined for the various sub-pathsand the computation of the composite connectivity for each tuple thathas been detected.

This is performed with separate reference to the forward direction orupstream, and the backward direction or downstream.

For each ISP of interest being considered a cycle is performed so thatfor each target system AS in the file FPX associated to the same ISP,the lines are searched that contain such a target system AS in a finalor intermediate position. Per each line that satisfies such a condition,an oriented sub-path is extracted and then used as a key for a temporaryassociative array having a value of the weight function calculated onthe basis of the length in number of AS hops of the extractedsub-string.

After processing the entire file, the paths and the different sub-pathscontribute to the connectivity from the ISP being considered up to theAS system being used as a target. The contribution is defined in apreferred way (it will be appreciated that this choice as such is notbinding, since it possible to make resort to different weighing laws) asthe product of the weight function evaluated on the basis of the lengthin AS hops of each sub-path multiplied by the traffic volume in bytesaddressed to the target AS.

The value of the overall connectivity from the ISP being considered upto the AS regarded as a target (together with the relating valuesidentifying the provider ISP and the system AS being considered) arewritten in a line of a corresponding output file.

This operation is performed as many times as the number of the ASsystems included in the set T of FIG. 1.

A similar cycle is carried out for each system AS considered as a targetto find out the backward connectivities up to the provider ISP underquestion.

Also in this case the search is made of the lines containing in aninitial or intermediate position the target system AS in the DPX fileassociated to the ISP being considered. Thus the associative array ofthe sub-paths from the target system AS up to the provider ISP underquestion is derived and the connectivity contribution of eachsub-strings is computed as the product of the traffic volume produced bythe target AS system by the weight function evaluated through the lengthin AS hops of the sub-path under question. The relating AS numberidentifiers and the resulting connectivity value are written in a lineof a corresponding file. Also in this case, the processing operation isperformed as many times as the number of AS systems comprised in thegroup T of FIG. 1.

The file of the total connectivities is produced by reading theindividual files and adding for each target AS system the forward andbackward connectivities.

Specifically, step 106 in the flow chart of FIG. 3 makes reference tothe computation operation of the connectivity with traffic weights andsub-paths, whilst step 108 indicates the choice of the individualprovider ISP being considered, selected from the file ASB. The stepindicated by 110 concerns the determination for each target AS system ofthe destination traffic, whilst step 112 collectively indicates theother operations previously described.

The computation of the composite connectivity is started at step 114.This is followed by step 116 wherein a tuple is read from the respectivefile determined at step 102, then calculating the value of theconnectivity from the first provider ISP of the tuple toward each targetsystem AS detected from the traffic file. Using the target system AS asa key of an associative temporary array the data accumulate of thedifferent paths from the first provider ISP previously considered towardthe target system AS being considered.

The same procedure is repeated for the other ISPs forming the currenttuple.

This holds true for the forward connectivity; a similar procedure shallapply for the backward direction and the file of the totals.

Specifically, the associative array is built for each provider ISPforming the current tuple. This takes place at step 118, where also thecomplete connectivity is obtained by setting then in a output file theconnectivity value attained, followed by the indication of the tuple forwhich it has been computed on the same line.

For each target AS the computation is made (through the weighing lawchosen, such as the algebraic sum to which reference was made before byway of an example) of the connectivity contribution of the tuple fromand toward the target AS under question.

At a subsequent step, denoted by 120, the files of the results obtainedare sorted according to decreasing connectivity values, obtained fromeach tuple of the ISP being considered or candidate ISP. This isaccomplished by using an associative array that has as a key theconnectivity value, sorting the keys or writing then the entire line ofthe input file in an ordered output file.

FIGS. 4 and 5 depict two examples of connectivity “standings” of thetype indicated above, produced in the form of disaggregated results forboth the backward and the forward direction.

It will be appreciated that tables of this type may be produced also asa global result of a backward/forward aggregated type.

Furthermore it will also be appreciated that the connectivitycomputation function of the tuple of provider ISPs can be implemented indifferent ways. As an example of an accumulation, reference has beenmade previously to a function of algebraic sum: experiments conducted bythe Applicant have proved that such choice is definitely advantageous,being at the same time extremely simple in its implementation.

The extraction of the BGP paths takes for granted the availability of astring defining the border of the AS path. Such a string may berepresented by a “weight” parameter (e.g. equal to 0) of the BGPinformation contained in the relating table, usually stored on therouter. The solution according to the invention is however notrestricted to such a choice.

It will be also appreciated that it is possible to write the code orscript in a more compact way, by using structures as references to theassociative arrays (they are essentially sort of a pointer) andsubroutines of various nature. The pointers allow one to use subroutinesto which parameters are passed, and which act upon each call on adifferent associative array. The use of a 64-bit floating pointarithmetic proves widely satisfactory for the modalities of operationdescribed before.

Obviously, keeping unchanged the principle of the invention, its detailsof implementation and the embodiments may be widely varied with respectto what has been previously described and illustrated, thus withoutleaving the scope of the present invention. This applies in particularbut not exclusively to the possibilities of performing connectivityevaluations concerning the forward direction only or the backwarddirection only.

1. A method for performing, for the benefit of a reference providerhaving a set of users, connectivity evaluations over a datacommunication network with respect to at least one provider of interestthe method comprising the steps of: selecting a plurality of autonomoussystems adapted to form a traffic source or a traffic destination forusers of said reference provider through the reference provider,supplying tables of Border Gateway Protocol type containing informationon paths available on said data communication network for routing saidtraffic with regard to the autonomous systems of said plurality ofsystems, extracting from said tables the paths of Border GatewayProtocol type associated with said at least one provider of interest, bysearching the paths that contain the respective number of autonomoussystem for said at least one provider of interest, extracting for eachautonomous system of said plurality of systems, oriented subpathsbetween each of said autonomous systems and said at least one providerof interest, by identifying for each subpath a respective length innumber of hops, identifying for each autonomous system of said pluralityof systems a forward traffic volume or a backward traffic volume withregard to the users of said reference provider, determining, for each ofsaid subpaths connectivity contribution as a function of the respectivelength in number of hops and of the forward traffic volume or thebackward traffic volume, determining for each autonomous system of saidplurality of systems total connectivity values accumulating theconnectivity contributions determined for the oriented subpathsextracted for each of said autonomous systems, and accumulating thetotal connectivity values determined for the autonomous systems of saidplurality of systems, so as to obtain total connectivity values relatingto said at least one provider of interest.
 2. The method according toclaim 1 wherein the steps are carried out for a plurality of providersof interest present on said data communication network.
 3. The method asrecited in claim 2, further comprising the step of: sorting the totalconnectivity values obtained for the providers of interest of saidplurality of systems in at least one sorted list.
 4. The method asrecited in claim 1, further comprising the steps of: identifying foreach autonomous system of said plurality of systems both the forwardtraffic volume and the backward traffic volume with regard to the usersof said reference provider, and determining for each of said subpathsrespective contributions of connectivity as a function of the respectivelength in number of hops and of both said volumes of forward traffic andbackward traffic.
 5. The method as recited in claim 4 further comprisingthe step of: generating values of total connectivity for said at leastone provider of interest disaggregated into values of total connectivityfor forward traffic and backward traffic.
 6. The method as recited inclaim 1 further comprising the step of submitting said tables of BorderGateway Protocol type to a clean-up operation to eliminate commentscontained in said tables.
 7. The method as recited in claim 2, furthercomprising the step of: selectively reallocating transit traffic throughsaid reference provider on at least one part of said providers ofinterest of said plurality of systems.
 8. A system for performing forthe benefit of a reference provider having a set of users connectivityevaluations on a data communication network with respect to at least oneprovider of interest, the system comprising: tables of Border GatewayProtocol type containing information on paths available on said datacommunication network for routing traffic with regard to a plurality ofautonomous systems adapted to establish at least a source or adestination for traffic of users of said reference provider through thereference provider, detection means for detecting, for each autonomoussystem of said plurality of systems, at least one between a forwardtraffic volume and a backward traffic volume with regard to the users ofsaid reference provider, and processing means for: extracting from saidtables the paths of Border Gateway Protocol type associated with said atleast one provider of interest, by searching for the paths that containthe respective number of autonomous system for said at least oneprovider of interest extracting for each autonomous system of saidplurality of systems oriented subpaths between said each autonomoussystem and said at least one provider of interest, identifying for eachsubpath a respective length in number of hops, determining for each ofsaid subpaths a connectivity contribution as a function of therespective length in number of hops and of said forward or backwardtraffic volume with regard to the users of said reference provider,determining for each autonomous system of said plurality of systemstotal connectivity values accumulating the connectivity contributionsdetermined for the oriented subpaths extracted for each said autonomoussystem, and accumulating the total connectivity values determined forthe autonomous systems of said plurality of systems, so as to obtainvalues of total connectivity relating to said at least one provider ofinterest.
 9. The system as recited in claim 8, configured for performingconnectivity evaluations for a plurality of providers of interestpresent on said data communication network.
 10. The system as recited inclaim 9, further comprising: means for sorting the total connectivityvalues obtained for the providers of interest of said plurality ofsystems in at least one sorted list.
 11. The system as recited in claim8 wherein: said detection means is configured for detecting for eachautonomous system of said plurality of systems, both the forward trafficvolume and the backward traffic volume with regard to the users of saidreference provider, and said processing means is configured fordetermining, for each of said subpaths, respective connectivitycontributions as a function of the respective length in number of hopsand of both said forward traffic volume and backward traffic volume. 12.The system as recited in claim 11 wherein said processing means isconfigured for generating total connectivity values for said at leastone ISP of interest, disaggregated into total forward connectivityvalues and total backward connectivity values.
 13. The system as recitedin claim 8 further comprising: pre-processing means for submitting thetables of Border Gateway Protocol type to a cleanup operation toeliminate comments contained in said tables.
 14. The system as recitedin claim 9 wherein the providers of interest of said plurality ofsystems are equipped with a selective re-balancing module forre-balancing the transit traffic through said reference provider.